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O (57) Abstract: A policy server is arranged to construct device-neutral policies for conflguring CBR for MPLS traffic engineering 
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tions and affinity profiles). The policy server defines the link attributes, assigns the link attributes to network interfaces, establishes 
»^ affinity profiles and attaches the affinity protites to MPLS tunnels. The link atuibute definitions and affinity profiles are shared 

across the network to construct the policies such that IP operators can configure CBR easily across a network. 
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SYSTEM. APPARATUS AND METHOD FOR SUPPORTING CONSTRAINT 
BASED ROUTING FOR MULTI-PROTOCOL LABEL SWITriltNC TR AFFir 
ENGINEERING IN POLICY-BASED MANAGEMENT 

Related Application 

This utility application claims benefit under 35 United States Code § 
1 19(e) of United States Provisional Application No. 60/467,066 filed on April 30, 2003. 

Field of the Invention 

This invention relates to data packet routing, and in particular, to policy 
management for configuring constraint based routing in multi-protocol label switching 
traffic engineering. 

Background of the Invention 
Packet-fonvarding policies are in place to administer, manage and 
control access to networic resources. Policy-based management employs a policy server 
to manage the network as a whole. The policy serv^ translates business goals or 
policies into configurations of network resources and automates the configurations 
across multiple different network elements and differrat technologies (e.g. MPLS and 
Diffserv). The centralized approach ensures policy consistency across multiple network 
elements. 

Multi-protocol label switching (MPLS) is a packet-forwarding 

technology that gives internet protocol (IP) operators a high degree of control over the 

paths taken by packets on their networics. MPLS may be used for traffic engineering 

purposes. Interior gateway protocols (IGP), such as open shortest path first (OSPF) and 

intra-domain intermediate system to intermediate system routing protocol (IS-IS), route 

IP packets based only on the destination address and the shortest path to reach the 

destination. In contrast, MPLS traffic engineering allows administrators to establish 

routes for certain customers based on information other than the shortest path, such as 

delay and bandwidth available along the path. Therefore, MPLS can relieve congestion 

1 
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and maximize bandwidth utilization by allowing multiple paths between source and 
destination. 

Constraint based routing (CBR) is an example of MPLS trafiBc 
engineering. The operator does not specify the path expUcitly but deprads on a CBR 
mechanism that has been implemented in the network to determine the path. With 
CBR, every router advertises traffic-engineaing attributes (e.g., maximum bandwidth, 
unresCTved bandwidth, etc.) for its interfaces to all other routers. OSPF and IS-IS 
protocols have been extended for that puipose. As a result of the advertisement, every 
rout^ obtains a traffic-engineering database in addition to the regular routing database. 
When a label switch path (LSP) with QoS requirements needs to be estabUshed, the 
ingress router computes the optimal path based on the traffic-engineering database and a 
path selection algorithm. The router then signals the path establishment witfi a label 
distribution protocol. The explicit path selected is conveyed throu^ the signaling 
protocol. 

Summary of the Invention 

This summary of the invoition section is intended to introduce the reader 
to aspects of the invention. Particular aspects of the invention are pointed out in other 
sections h^ein below, and the invoition is set forth in the appended claims, which alone 
d^arcate its scope. 

The present invention is directed to a system for configuring constraint 
based routing (CBR) in multi-protocol label switching (MPLS) traffic engineering wiih 
a policy-based management approach across a network. The syst^ includes netwoilc 
interfaces where link attribute definitions are set, affinity profiles that relate to preferred 
link attributes, and a policy server. The policy server attaches the affinity profiles to a 
MPLS turmel such that the affinity profiles are shared across the network to construct 
service and network policies. 

Another aspect of the present invention is directed to an apparatus for 
configuring CBR in MPLS traffic engineering with a policy-based management 
^proach across a network. The apparatus includes a service ^plication, a central 
processing facility and a policy consumer. The service application configures policies, 

2 
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The central processing facility translates the policies into device-neutral policy 
parameters. The policy consumer translates the device-neutral policies into device- 
specific commands and dq)loy5 the device-specific commands to policy targets, such 
that the policies are constructed across the network. 
5 Anoth^ aspect of the present invention is directed to a method for 

supporting CBR for MPLS traffic engineering across a network. The method includes: 
defining link attributes; assigning the link attributes to network interfaces; establishing 
affinity profiles that specify preferred traffic engineering attributes; and attaching the 
affinity profiles to MPLS tunnels such that service and networic policies are constructed 
1 0 across the network. 

Another aspect of tfie present invention is directed to an ^aratus for 
coiifiguring C3R in MPLS traffic »guieering with a policy-based management 
approach across a network. The apparatus comprises: a means for defining link 
attributes; a means for assigning the link attributes to network interfaces; a means for 
1 5 establishing affinity profiles that specify preferred traffic engineering attributes; and a 
means for attaching the affinity profiles to MPLS tunnels such that service and network 
policies are constructed across the netwoik. 



Brief Descriptiop of the Drawings 

20 FIGURE 1 is a block diagram illustrating the architecture of a policy 

server; 

FIGURE 2 is a block diagram illustrating the architecture of a service 

application; 

FIGURE 3 is a block diagram illustrating the interaction of a service 
25 policies object with the sen^ice application; 

FIGURE 4 is a block diagram illustrating the structure of a networic 
policies object; 

FIGURE S is a block diagram illustrating the policy elements of a device 

object; 
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FIGURE 6 is a block diagram illustratiiig the policy elemmts of a MPLS 

tunnels object; 

FIGURE 7 is a diagram illustrating a network inq>lementing the policy 
servCT of the present invention; . 

FIGURE 8 is a flow diagram illustrating a method for configuring link 
attributes and affinity profiles to support CBR for MPLS traffic oigineering; 

FIGURE 9 is a flow diagram illustrating a method for deploying a policy 
to policy targets; and 

FIGURE 10 is a block diagram illustrating the method implemented in a 
3G netwotk, in accordance widi aspects of the invention. 

Detailed Description of the Preferred Emhiidlmi^nt 
In the following detailed description of exmiplary embodiments of the 
invention, reference is made to the accompanied drawings, which form a part hereof, 
and which is shown by way of illustration, specific exemplary embodiments of which 
the invention may be practiced. These embodiments are described in sufficient detail to 
enable those skilled in the art to practice the invention, and it is to be underetood that 
other embodiments may be utilized, and other changes may be made, without departing 
fix)m the spirit or scope of the present invention. The following detailed decription is, 
therefore, not to be taken in a limiting sense, and the scope of the preset invention is 
defined only by the {q>pended claims. 

Briefly stated, a policy server is arranged to construct device-neutral 
policies for configuring constraint based routing (CBR) for multi-protocol label 
switching (MPLS) traffic engineaing across a network. The policy server translates the 
device-nratral policies into device-specific commands. The policy server defines link 
attributes, assigns the link attributes to networic interfaces, establishes affinity profiles 
and attaches the affinity profiles to MPLS tunnels. The link attribute definitions and the 
affinity profiles are shared across the network to construct the policies such that IP 
operators can configure CBR easily across a network. 
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FIGURE 1 illustrates a block diagram of the architecture of a policy 
server that siq>ports differentiated services (Difi&erv) over MPLS traffic enginemng. 
Policy server 10 includes service ^plication 12» cmtral processing facility 14» and 
policy consumer 16 all coiq>led to database 18 through database access 20 which 
provides interfaces for database 18 read and write operations. 

Service iq)plication 12 is a grq>hical user inter&ce (GUI) that allows IP 
operators to configure policies (i.e., operators can add, delete or modify policies.) 
Central processing facility 14 translates the policies into device-neutral policy 
parameters and stores tfie policy paramrters in database 18. Cratral processing fecility 
14 also conducts policy verification, conflict detection and resolution. Policy consumer 
16 provides an interface for central processing facility 14 to communicate with policy 
targets. A policy target refers to any netwoik node ^^e the policy is enforced such as 
a router. PoUcy consume 16 translates the device-neutral policies stored in database 1 8 
into device-specific commands, and deploys the device-specific commands to the policy 
targets. 

According to one embodiment, service policies and network policies are 
used. Service policies refer to rules that govern the treatment of individual customer 
traffic, such as traffic classification, metering and marking. Network policies refer to 
rules that govern the treatment of aggregated traffic, such as queue and scheduler 
configurations for behavior aggregates. For example, an IP operator may modify 
service policies when a new service level agreement (SLA) is created or when an 
existing SLA is modified. An IP opetdior may modify network policies when new 
facilities are added into a network or when traffic patterns are changed significantly. In 
a large netwoik, the same set of policies can be applied to multiple routers or network 
interfaces. To achieve better scalability, n^ork interfiices are assigned role names and 
the policies are specified and associated with the roles name. Network interfaces 
identified by the same role names receive the same set of policies. 

A common information model describes policies as relationships 
between network objects. The information model derives database schema for database 
18 such that the policy stored in database 18 is device-neutral. In a multi-vendor 
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environment where routers firom different vradors are configured through different 
protocols, policy server 10 translates the policy stored in database 18 into device- 
specific commands and delivers the resulting policy throu£|i the specific protocol. The 
infoimation model mables a consistent provision of policies across multi-vendor 
networks. 

FIGURE 2 illustrates a block diagram of the architecture of service 
application 12. Service application 12 includes sendees object 24, application object 
26, customer object 28, devices object 30, MPLS tunnels object 32 and network policies 
object 34. Services object 24, q>plications object 26, and customer object 28 are related 
to SCTvice policies. Devices object 30, MPLS tunnels object 32, and network policies 
object 34 are related to network policies. 

Services object 24 allows IP operators to define the services to be 
provided to customers. According to one embodiment, each service is defined as a 
mapping between a service name and any of the fourteen DSCP numbers defined by the 
Internet Engineering Task Force (IETF), implication object 26 allows IP operators to 
define applications for the classification of traffic flows such as protocol, source port 
and destination port ranges. Customer object 28 allows IP operators to define service 
policies for each customer. Customer object 28 may also contain host groups and 
metering profiles associated with each customer. Devices object 30 contains 
information about network elraients that receive the policies fiiom policy server 10. IP 
operators use devices object 30 to assign role names to the netwoilc interfaces. Most 
other policy target information in devices object 30 is directly imported into database 1 8 
fiom an element management database. MPLS tunnels object 32 allows IP operators to 
configure the MPLS network componrats such as turmel group, explicit routes, CBR 
and EXP-PHB mapping, i.e., MPLS tunnels object 32 specifies the MPLS and 
Difi&erv/MPLS policies. Network policies object 34 allows IP operators to define the 
network policies that specify the queuing and scheduling treatment of a specific service 
and that are attached to specific network interfaces. 

FIGURE 3 illustrates a block diagram of the interaction between a 
service policies object and service application 12. S^ce policies object 36 includes 
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rules that govern the treatment of individual customer traffic such as classification and 
metering rules. The classification rules include an ai^lication name supplied by 
application object 26 and source/destination host groups supplied by customer object 
28. The metering rules use an algorithm specified by traffic profiles i^ch are supplied 
S to service policies object 36 by customer object 28. Devices object 30 provides role 
names to service policies object 36 such that service policies object 36 can be applied to 
the network int^aces. MPLS tunnels object 32 provides information about tunnel 
group and tunneling mode to service policies object 36. Service policies object 36 
defines non-confoimance action (e.g.t marking or dropping) after metering, and maps 

10 the traffic into the desired NIPLS tunnels and tuimeling mode. 

FIGURE 4 illustrates a block diagram of the structure of die network 
policies object Devices object 30 allows operators to assign role names to the network 
interfaces. Network policies object 34 specifies the Dif&erv configuration and applies 
the configuration to the role names. Network policies object 34 then deploys the 

1 S network policies to the networic interfaces through the associated role names. 

Services object 24 provides service names to network policies object 34. 
The service name selects the DifFserv class that supports classified traffic. Network 
policies object 34 defines the PHB used to support a particular service or DiflOserv class, 
such as queuing and scheduling. In each network interface, all LSPs share the same 

20 queue if they have the same PSC, and no per-LSP queuing is employed. 

FIGURE 5 illustrates a block diagram of the policy elements of the 
device object The policy elements set link attributes 37 in each network interface 38. 
PoUcy server 10 defines the sCTiantics of link attributes 37 and affinity profiles 
supported by link attribute definititon object 40. Link attribute definition object 40 

25 allows IP operators to define a high-level representation for each affinity bit, such as the 
specific data rate, link technology or virtual private network (VPN) membership. In 
one embodiment, each representation consists of a bit position, attribute names and a 
category. In another embodiment, each representation consists of a bit position and an 
attribute name. An example of an attribute name is **Ethemet*' and an example of a 

30 category is "Link Technology^'. Link attributes 37 are then stored in database 18 and 
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shared across different objects. For instance, link attributes 37 can be added to each 
network interface. Thus, IP operators can select the correct link attributes to describe 
the network interface. 

FIGURE 6 illustrates a block diagram of the policy el^rats of the 
S MPLS tunnels object. The policy elements include tunnel group 42» tuimel 

characteristics object 44, explicit route object 46, a£Bnity profile object 48, and EXP- 
service map SO. Tunnel group 42 is a set of tunnels that share the same properties and 
form a certain topology, such as a mesh or a star. Tunnel gjmsp 42 configures (i.e., 
creates, maintains and deletes) MPLS tunnels such that IP operators do not need to 

10 create tunnels individually. Instead, IP opmtors specify the end-point routm and the 
intor-connecting topology. The int^nal routes travosed by a tunnel are detoinined by 
the underlying routing protocols, such as OSPF or IS-IS. In tfie case of star topology, 
the hub and the spokes are specified explicitly. 

Tunnel duuiu^teristics object 44 includes profiles that specify the 

IS parameters for resource reservation and policing per MPLS tunnel. Explicit route 
object 46 allows IP operators to explicitly specify the optimal path for forwarding 
packets. Explicit route object 46 contains a list of interface links that an explicit route 
LSP traverses through. The list of IP addresses can be a partial or complete route. 
There can be more than one explicit route list and thus a pointer is necessary to link the 

20 list to tunnel group 42. In addition, each explicit route LSP is unidirectional. 

Therefore, a bidirectional LSP requires configuration of two explicit route LSPs in 
opposite directions. 

There are two steps in configuring tunnel group 42 using CBR: setting 
the link attributes and attaching affinity profile object 48 to tunnel group 42. AfEuiity 

2S profile object 48 defines affinity profiles that select the preferred link attributes in 
routing. An afiSnity profile indicates whether each attribute defined in link attribute 
definition object 40 is preferred, not preferred, or ''don't care." An affinity profile is 
linked explicitly to a tunnel group. Central processing facility 14 then converts the 
affinity profile into device neutral inforaiation for storage in database 18, which is then 

30 used with an extended IGP protocol to support CBR. 
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TTie linking of tunnel groiq) 42 in service policies object 36 identifies the 
LSPs that cany customo- traffic. Tunneling mode decides which Dif&erv code point 
(DSCP) is carried in the IP headas when a packet exits the MPLS netwoik. ThCTe are 
two essential modes of tunneling: pipe mode and unifomi mode. For pipe mode, the 
egress router keeps the DSCP of the encapsulated IP header. For unifonn mode, the 
egress router overwrites the original DSCP with the Difl&erv information in the MPLS 
netwoik. Tunnel group 42 and tunneling mode are used if operators use MPLS to cany 
customer traffic. If MPLS is not used, tunnel group 42 and tunneling mode can be left 
empty. 

FIGURE 7 illustrates a diagram of a network implementing the policy 
server according to aspects of the invention. Netwoik 54 includes two edge routers 56 
and two cote routers 58, Policy server 10 can construct multiple LSPs between edge 
routers 56 through explicit route or CBR, as indicated by arrows 60. Policy server 10 
can also map customer X and customer Y into one LSP or split them into two LSPs by 
service poUcie?. In addition, policy server 10 can assign different customer applications 
into different Diffierv classes by service policies, and allocate the resources accordingly 
by network policies. 

According to embodimoits of the invention, two sqpproaches for policy 
dqjloyment onto routers 56, 58 can be implemented. The first approach is generating a 
new configuration file to replace the file cunentiy in use by the router. FIGURE 8 
illustrates a flow diagram of the second approach. The current configuration of a router 
is determined at block 62. The configuration includes information about access Usts, 
classification rules, policies, MPLS tunnels, and the like. The router is reconfigured at 
block 63. The router is reconfigured by deleting unwanted policies and replacing the 
unwanted policies with new command line interface (CU) commands based on the 
current set of policies to be deployed. 

FIGURE 9 illustrates a flow diagram of a method implemented in the 
policy server for configuring link attiibutes and affinity profiles according to aspects of 
the invention. An atttibute editor is added to the poKcy server at block 64. The 
attribute editor allows operators to define and edit the meaning of attiibutes supported 
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across the network. Examples of the definition can be related to geography, link speed, 
VPN group m^bership, and the like. 

The link attributes defined in the attribute editor are configured for each 
network interface at block 66. Any change in the attribute editor is automatically 
5 reflected in the network interface configuration. The GUI for network inter&ces 

displays the attribute names defined in the attribute editor thus allowing IP operators to 
select the link attributes that describe the characteristics of any networic interface. Each 
inter&ce can have different link attribute settings. Thus, the attribute editor hides the 
device-specific details for supporting link attributes and allows IP operators to 
1 0 configure the link attributes easily. 

Affinity profiles are added to the policy server at block 68. Each affinity 
profile specifies which link attributes are prefored, which attributes are not preferred 
and Mdiich attributes are '^don't care" values. Any modification in the attribute editor is 
automatically reflected in the affinity profiles. IP operators can configure (i.e., create, 
15 delete and edit) the aflSnity profiles. The policy server translates each afiBnity profile 
into device-specific commands at block 70. The policy server stores device-neutral 
information associated with each affinity profile in the policy server database at block 
72. 

An affinity profile is attached to an MPLS tunnel or tunnel group by the 
20 policy server at block 74. A tunnel group refers to an identifier that rq)resents a 
collection of MPLS tunnels that share the same properties and are connected by a 
certain topology. A tunnel group provides a mechanism to attach an afllnity profile to 
multiple tunnels. An extended interior gateway protocol (IGP) supports MPLS traffic 
engmcOTng and selects the optimal path based on affinity profiles and advertised link 
25 attributes. The affinity profiles are shared across the network. Thus, two diff^^t 
tunnel groups or MPLS tunnels can reuse the same affinity profile. The policy server 
uses the affinity profile in constructing the device-specific conunands to establish the 
MPLS tunnels. 

The above-described methods can be implemented in an existing MPLS 
30 policy server to support CBR for MPLS traffic engineering. nOURE 10 illustrates an 
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example of (he methods implemented in third generation (3G) networics. MPLS tunnels 
82 are established across an IP transport network 84, which include public land mobile 
networks (PLMN), to provide VPN siqiport MPLS tunnels 82 provide pathways 
between IP networks 86 and radio access networks 88. The method provides IP 
S operators with a unified management tool that can configure serving edge routers 90 to 
si4>port CBR. According to one raibodiment, edge routers 90 include general packet 
radio s^ce (GPRS) support nodes (SGSN), gateway GPRS support nodes (GGSNs) 
and third party MPLS routm. 

The above q^ecification, examples, and data provide a complete 
10 description of die manufacture and use of the conq)osition of the inventiort Since many 
onbodiments of the invration can be made without dq>arting fiom the spirit and scope 
of tfie invention, the invention resides in the claims herdnafier appended. 
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10 



WE CLAIM: 

1 . A system for configuring constraint based routing (CBR) in 
multi-protocol label switching (MPLS) traffic engineering with a policy-based 
management approach across a netwoiic, comprising: 

network interfaces that are airanged to have link attribute definitions set; 

affinity profiles that relate to preferred link attributes; and 

a policy server that is arranged to attach the affinity profiles to a MPLS 

tunnel such that the affinity profiles and the link attribute definitions are shared across 

the network to constmct service and networic policies. 

2. The system of claim 1 , wherein the affinity profiles are device- 
neutral and wherein the policy server is fiuther arranged to translate the affinity profiles 
into device-specific conmiands. 



15 3. The system of claim 1 , wherein the pohcy server is fiuther 

airanged to assign the link attributes to the network interfaces by determining the 
current configuration of a router, configuring the router, and issuing new commands 
based on the set of link attributes to be assigned. 

20 4. The system of claim 1 , wherein the policy server comprises a 

user interface that allows an operator to configure the service and network policies. 

5. The system of claim 1 » wherein the policy server is fiuther 
arranged to configure the MPLS tunnels such that an operator can create an MPLS 

25 tunnel by specifying end*point routers and inter-connecting topology. 

6. The system of claim 1 , fiirther comprising a database for storing 
the affinity profiles, the link attribute definitions and the link attributes of each network 
interface. 

12 
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7. The syston of claim 1, fuith^ coiiq)rising a link attribute 
definition object tfiat is anranged to define Ae semantics of the link attributes and the 
afiBnity profiles. 

8. The system of claim 7. whmin the link attribute definition object 
is further airanged to describe a policy target by defining a representation for each 
attribute bit and for each affinity bit in the afiBnity profile. 

9. The systCTi of claim 8, wherein the representation comprises at 
least one of a bit position, an attribute name and a category/ 

10. An apparatus for configuring CBR in MPLS traffic engineering 
with a policy-based management approach across a network, comprising: 

a service application that is airanged to have policies configured; 

a central processing facility that is arranged to translate the policies into 
device-neutral policy paramet^; and 

a policy consumer that is arranged to translate the device-neutral policies 
into device-specific commands, and that is further arranged to deploy the device- 
specific commands to policy targets, such that the policies are constructed across the 
network. 

1 1 . The apparatus of claim 1 0, further conq>rising a database for 
storing the policy parameters. 

12. The iq>paratus of claim 10, wherein the sovice ^plication 
comprises a MPLS object that is arranged to configure MPLS tunnels such that an 
MPLS tunnel can be created by specifying end-point routers and inter-connecting . 
topology. 



13 
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13. The apparatus of claim 10, wherein the s^rice application 
comprises a devices object and a network policies object, the devices object assigning 
role names to network interfaces, the network policies object deploying the policies to 
the policy targets based on the assigned role names such that the network interfaces 
having the same role names receive the same policy. 

14. The system of claim 10, wherein the service iq>plication further 
comprises a link attribute definition object that is arranged to define the semantics of 
link attributes, affinity profiles, and attribute bits such that a rq)resentation is defined 
for each aflSnity bit in an affinity profile to choose a n^ork int^^K^e. 

15. The system of claim 14, wherein the rqiresratation comprises at 
least one of a bit position, an attribute name and a category. 

16. A method for supporting CBR for MPLS traffic engineering 
across a network, comprising: 

defining link attributes; 

assigning the link attributes to network int^aces; 

establishing affinity profiles that specify preferred traffic engineering 

attributes; and 

attaching the affinity profiles to MPLS tunnels such that service and 
network policies are constructed across the network. 

1 7. The method of claim 1 6, further comprising storing the affinity 
profiles, the link attribute definitions and the link attributes of each network int^face in 
a database. 

1 8. The method of claim 16, further comprising translating the 
affinity profiles into device-specific commands 
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19. The method of claiiii 16, fiirthar comprising storing device- 
neutral information associated with the afiSnity profiles in a database. 

20. The method of claim 16, i^eroin assigning the link attributes to 
5 network interfaces further comprises: 

determining the command configuration of a router, 
configuring the router; and 

issuing new conunands to the router based on the link attributes to be 

assigned. 

21. An apparatus for configuring CBR in MPLS traffic engineering 
with a policy-based management approach across a network, comprising: 

a means for defining link attributes; 

a means for assigning the link attributes to network interfaces; 
a means for establishing affinity profiles that specify preferred traffic 
mgineering attributes; and 

a means for attaching the affinity profiles to MPLS tunnels such that 
service and network policies are constructed across the network. 

22. The method of claim 21, further comprising a means for 
20 translating the affinity profiles into device-specific commands. 
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